Peer-to-peer bus segment bridging

ABSTRACT

A method and apparatus are described for facilitating proper ordering of peer-to-peer communications between bridged bus segments. According to one embodiment of the present invention a fence command is issued when a peer-to-peer communication between devices on separate bus segments connected on the same side of a bridge is detected. The fence command is inserted into a plurality of buffers in an I/O hub corresponding to the bus segments to force temporary ordering across all pipes of the I/O hub. The hub prohibits processing of subsequent commands from a buffer once a fence command has been read from that buffer until a corresponding fence command is read from all other buffers in the plurality of buffers therby assuring proper ordering of the peer-to-peer communication.

FIELD

[0001] The invention relates generally to the field of bus environmentand bridge applications. More particularly, the invention relates tofacilitating peer-to-peer communications between bridged bus segments.

BACKGROUND

[0002] Bus environments increasing rely on high bandwidth Input/Output(I/O) connections and components. One common application of a highbandwidth I/O interconnect is a bridging component that may, on oneside, support a standard bus such as a Peripheral Component Interconnect(PCI) bus. The bridge may support single or multiple bus segments. Thebridge then interconnects these bus segments to other system resources,such as main memory. Communications initiated on one of the bus segmentsthen passes through the bridge and onto the interface with the othersystem resources.

[0003] Bus standards, such as PCI, provide a multi-drop bus. That is,multiple bus agents (devices) may exist on the same bus. On suchmulti-drop buses, it is easy to read from or write to other devices onthe same bus. For example, a personal computer (PC) typically containsone PCI bus. In this case, it is easy for one device on the bus toperform a peer-to-peer communication with another device on the samebus.

[0004] However, as bus interface speed increases, bus architectures aremoving away from multi-drop architectures and toward point-to-pointarchitectures. As bus speed increases, point-to-point architecturesbecome more important because a bus cannot operate at higher speeds withthe load of multiple cards on the same interface. In architecturessupporting multiple independent buses, peer-to-peer communications arenot as straight forward as with the multi-drop bus. Synchronization ismore important if peer-to-peer traffic is present in a point-to-pointarchitecture. That is, with point-to-point architectures, properordering of the communications becomes important.

[0005] For example, two devices on separate bus segments connected onthe same side of a bridge may communicate with one another. Keeping thispeer-to-peer communication within the bridge and not passing it thoughto the other side of the bridge would yield greater performance.However, proper ordering of these peer-to-peer communications with thosethat do traverse the bridge then becomes an issue since, due topropagation and processing delays, various components of the busenvironment may handle the communications out of order.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The appended claims set forth the features of embodiments of theinvention with particularity. The invention, together with itsadvantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

[0007]FIG. 1 is a block diagram illustrating a typical dual-headed PCIbridge and I/O hub;

[0008]FIG. 2 is a block diagram illustrating a dual-headed PCI-to-PCIbridge and I/O hub according to one embodiment of the present invention;

[0009]FIG. 3 is a block diagram illustrating data flow in a dual-headedPCI-to-PCI bridge and I/O hub according to one embodiment of the presentinvention;

[0010]FIG. 4 is a block diagram illustrating data flow with a fencecycle in a dual-headed PCI-to-PCI bridge and I/O hub according to oneembodiment of the present invention;

[0011]FIG. 5 is a flowchart illustrating a high-level view of a producerdata write process;

[0012]FIG. 6 is a flowchart illustrating bridge processing according toone embodiment of the present invention;

[0013]FIG. 7 is a flowchart illustrating hub processing according to oneembodiment of the present invention;

[0014]FIG. 8 is a block diagram illustrating a dual-headed PCI-to-PCIbridge and I/O hub according to an alternative embodiment of the presentinvention; and

[0015]FIG. 9 is a block diagram illustrating data flow with a fencecycle in a dual-headed PCI-to-PCI bridge and I/O hub according to analternative embodiment of the present invention.

DETAILED DESCRIPTION

[0016] A method and apparatus are described for facilitating properordering of peer-to-peer communications between bridged bus segments.According to one embodiment of the present invention a fence command isissued when a peer-to-peer communication between devices on separate bussegments connected on the same side of a bridge is detected. The fencecommand is inserted into a plurality of buffers in an I/O hubcorresponding to the bus segments to force temporary ordering across allpipes of the I/O hub. The hub prohibits processing of subsequentcommands from a buffer once a fence command has been read from thatbuffer until a corresponding fence command is read from all otherbuffers in the plurality of buffers therby assuring proper ordering ofthe peer-to-peer communication.

[0017] In the following description, for the purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding. It will be apparent, however, to one skilled in the artthat embodiments of the present invention may be practiced without someof these specific details. In other instances, well-known structures anddevices are shown in block diagram form.

[0018] Embodiments of the present invention include various processes,which will be described below. The processes may be performed byhardware components or may be embodied in machine-executableinstructions, which may be used to cause a general-purpose orspecial-purpose processor or logic circuits programmed with theinstructions to perform the processes. Alternatively, the processes maybe performed by a combination of hardware and software.

[0019] Embodiments of the present invention may be provided as acomputer program product which may include a machine-readable mediumhaving stored thereon instructions which may be used to program acomputer (or other electronic devices) to perform a process. Themachine-readable medium may include, but is not limited to, floppydiskettes, optical disks, Compact Disk Read-Only Memories (CD-ROMs), andmagneto-optical disks, Read-Only Memories (ROMs), Random Access Memories(RAMs), Erasable Programmable Read-Only Memories (EPROMs),Electronically Erasable Programmable Read-Only Memories (EEPROMs),magnetic or optical cards, flash memory, or other type ofmedia/machine-readable medium suitable for storing electronicinstructions. Moreover, embodiments of the present invention may also bedownloaded as a computer program product, wherein the program may betransferred from a remote computer to a requesting computer by way ofdata signals embodied in a carrier wave or other propagation medium viaa communication link (e.g., a modem or network connection).

[0020] Importantly, while embodiments of the present invention will bedescribed with reference to PCI, the method and apparatus describedherein are equally applicable to other multi-drop bus standards thatimpose ordering requirements on communications.

[0021]FIG. 1 is a block diagram illustrating a typical PCI-to-PCI bridgeand I/O hub. This example illustrates an I/O hub 120 and a dual-headedPCI bridge 110. Connected with the I/O hub 120 via a communication link126 is a system memory 130. The I/O hub 120 also has an interface 116for connection with the PCI bridge 110. Of course, the communicationlink 126, in actual applications, may not provide a direct link as shownhere. The link 126 may connect to another device such as an interface orcontroller not shown here for simplicity. Additionally, this exampleillustrates only one PCI bridge 110 and one interface 116 between theI/O hub 120 and the single PCI bridge 110. However, in practice,multiple interfaces 116 and multiple bridges 110 may be used. The I/Ohub 120 also includes a buffer (also referred to herein as a “pipe”) 121for temporarily storing communications between the PCI bridge 110 andsystem memory 130. In some applications, this buffer 121 may comprise aqueue or random access buffers. Additionally, the bridge 110 may beother than dual-headed and other than PCI. For example, the bridge maysupport four independent buses and may use protocol such as ThirdGeneration Input/Output Architecture (3GIO) or other current or futureinterconnect protocol.

[0022] The PCI bridge 110 includes an internal bus 111 with which theinterface 116 to the I/O hub 120 is connected. In some applications,there may be a buffer (not shown) positioned between the PCI bridgeinternal bus 111 and the interface 116 to the I/O hub 120. The PCIbridge 110 also includes a plurality of connections 112 and 113 with theinternal bus 111, buffers 114 and 115, and two independent bus segments145 and 155 collectively referred to as “pipe” A and “pipe” B. Ofcourse, more than two sets of connections, buffers, and independent bussegments may be present. In overview, the bridge 110 in this example hasordering buffers 114 and 115 for each bus segment 145 and 155 andconnections 112 and 113 to an internal bus 111 to allow interactionbetween devices 140 and 150 connected with the bus segments 145 and 155and between the devices 140 and 150 and system memory 130 via the I/Ohub 120. The ordering buffers 114 and 115 may comprise queues or randomaccess buffers.

[0023]FIG. 2 is a block diagram illustrating a dual-headed PCI-to-PCIbridge and I/O hub according to one embodiment of the present invention.This example, as with the example illustrated in FIG. 1, illustrates anI/O hub 220 and a PCI bridge 210. As in FIG. 1, connected with the I/Ohub 220 via a physical communication link 226 is a system memory 230.The I/O hub 220 also has an interface 216 for connection with the PCIbridge 210. The I/O hub 220 in this example includes a plurality ofbufers 221 and 222 for temporarily storing communications between thePCI bridge 210 and system memory 230. These buffers correspond to thebuffers 214 and 215 of the PCI bridge 210. In other words, the contentsof the buffers 214 and 215 of the independent bus segments 245 and 255of the PCI bridge 210 are transferred to the separate buffers 221 and222 of the I/O hub, allowing the “pipes” to remain independent.Therefore, the two separate buffers allow traffic from one bus segmentto have no ordering implications on traffic from the other bus segment.The buffers 221 and 222 may comprise queues or random access buffers inwhich the content from the independent “pipes” is distinguished bycontrol logic.

[0024] To allow the plurality of buffers 214 and 215 to be transferredover the single interface 216 between the bridge 210 and the I/O hub 220and mapped to the proper buffer 221 and 222 in the hub 220, the bridge210 identifies each transaction with the bus from which it came. Thismay be done with an identifier tagged to each transaction and used tode-multiplex the transaction at the I/O hub 220. According to oneembodiment of the present invention, the identifier comprises a “pipe”designator made up of a combinations of a hub identifier (HubID) andpipe identifier (PipeID).

[0025] Bus standards such as PCI have ordering rules. For example, if awrite command is issued followed by a read command, the read cannot passthe write in order to prevent reading of stale data. Without independentbuffers 221 and 222 in the I/O hub, a write command from one busfollowed by a read command from another bus may cause these orderingrules to be applied unnecessarily to independent transactions. When theI/O hub contains a single buffer, as illustrated in FIG. 1, when thecommands reach the single buffer of the I/O hub they are no longertreated independently, as the I/O hub does not know that they wereseparate and imposes ordering requirements whether necessary or not.However, a new problem may arise that will be described in greaterdetail below. Briefly, the problem arises that the producer/consumermodel may be violated if one buffer is processed faster than the other.

[0026]FIG. 3 is a block diagram illustrating data flow in a dual-headedPCI-to-PCI bridge and I/O hub according to one embodiment of the presentinvention. In this example, devices 340 and 350 on separate, independentbus segments 345 and 355 are writing and reading data following aproducer/consumer model. Here, the device 340 on “pipe” A functions asthe producer and the device 350 on “pipe” B functions as the consumer.Assume, for the sake of discussion, that the data 335 resides in systemmemory 330 while a flag 351 or semaphore indicating the availability ofnew data resides on device 350 on “pipe” B, the consumer. Of course, theproducer, consumer, data and flag may reside anywhere on the system.

[0027] In this example, the producer 340 writes the data 335 andsubsequently writes 346 the flag 351. The two writes keep in orderthrough the PCI bridge 310. The data write is sent to the I/O hub 320and the system memory 330 while the flag write 346 is a peer-to-peerwrite and is written directly to the local memory of the consumer 350.The consumer 350 is polling the flag 351 and eventually sees it has beenupdated by the producer 340. The consumer 350 then proceeds to read thedata 335 from system memory 330.

[0028] In this example, the two bus segments 345 and 355 of the bridge310 are mapped using two different “pipes.” That is, all I/O trafficfrom the producer 340 is mapped to a single pipe represented by buffer314 in the bridge 310 and buffer 321 in the hub 320 and all traffic fromthe consumer 350 is mapped to another single pipe represented by buffer315 in the bridge 310 and buffer 322 in the hub 310. Since transactionsin different “pipes” are independent and allowed to be processed out oforder within the I/O hub, it is possible for the data read request 325in “pipe B” from the consumer 350 to pass the write data request 323 in“pipe A” from the producer 340. This will break the producer-consumermodel since the consumer might read stale data from the main memory.

[0029] In order to prevent such a violation of the producer consumerrules, the PCI bridge may issue a fence command to the I/O hub whenevera peer-to-peer write occurs within the bridge. Alternatively, as will bediscussed below, the fence command may be issued by the device issuingthe write command. According to one embodiment of the present invention,the fence command forces all preceding posted write commands to beobserved by the system before any subsequent commands are allowed toproceed. In this manner, the fence command forces ordering across allpipes and the data read will be forced to follow all preceding writecommands including the data write initiated on another bus segment.

[0030]FIG. 4 is a block diagram illustrating data flow with a fencecycle in a dual-headed PCI-to-PCI bridge and I/O hub according to oneembodiment of the present invention. In this example, as with theexample illustrated in FIG. 3, devices 440 and 450 are on separate,independent bus segments 445 and 455 and are writing and reading datafollowing a producer/consumer model. The device 440 on “pipe” Afunctions as the producer and the device 450 on “pipe” B functions asthe consumer. The data 435 resides in system memory 430 while the flag451 or semaphore resides on the device 450 on “pipe” B, the consumer.

[0031] In this example, the producer 440 writes the data 435 andsubsequently writes 446 the flag 451. The two writes keep in orderthrough the PCI bridge 410. The data write is sent to the system memory430 via the I/O hub 420 while the flag write 446 is a peer-to-peer writeand is directed to the consumer 450. According to one embodiment of thepresent invention, based on the transaction information, the bridge 410may identify the flag write as a peer-to-peer write and generates afence. The fence is then sent 417 and 418 to both buffers 421 and 422 ofthe I/O hub 420 where they are inserted 424 behind the data writecommand 423. Alternatively, the fence command may be written into thequeues 414 and 415 in the bridge 410 behind the write flag command 446and transferred from the queues 414 and 415 of the bridge 410 to thequeues 421 and 422 of the hub 420 along with other data in the “pipes.”

[0032] With the fence command 424 inserted into both buffers 421 and 422of the I/O hub after the data write command 423 but before subsequentcommands such as the data read 425, the I/O hub may process the buffers421 and 422 independently. Then, once a fence command 424 is encounteredin either buffer 421 or 422, the processing of that buffer is suspendeduntil the corresponding fence is encountered in the other buffer. Inthis manner, the data read command 425 cannot be handled before the datawrite command 423 and the producer/consumer model will not be violated.

[0033]FIG. 5 is a flowchart illustrating a high-level view of a producerdata write process. First, at processing block 505, the producer issuesa write data command as discussed above. Next, at processing block 510,the producer issues a write flag command also as discussed above. Thewrite flag command may be, as described, a peer-to-peer write to anotherdevice on an independent bus. This is the transaction that triggers theissuance of the fence command by the producer or bridge, depending uponthe particular implementation.

[0034]FIG. 6 is a flowchart illustrating bridge processing according toone embodiment of the present invention. First, at decision block 605, adetermination is made whether a write command issued by a first deviceis a peer-to-peer write command directed to a second device on anotherbus connected on the same side of the bridge. Next, at processing block610, a fence command is issued responsive to the write command beingdetermined to be a peer-to-peer write command. As explained above, thefence command is written into each buffer of a plurality of buffers inan I/O hub connected with the bridge.

[0035]FIG. 7 is a flowchart illustrating hub processing according to oneembodiment of the present invention. First, at processing block 705,data is read from at least one of a plurality of buffers in an I/O hub.At decision block 710, a determination is made whether a fence commandhas been read from the buffer. At decision block 715, a determination ismade whether a corresponding fence command has been read from all otherbuffers in the plurality of buffers. If a corresponding fence has notbeen read from all other buffers, processing of subsequent commands frombuffers from which a fence has been read is suspended and all otherbuffers are processed at processing block 720 until all correspondingfence commands are read.

[0036]FIG. 8 is a block diagram illustrating a dual-headed PCI-to-PCIbridge and I/O hub according to an alternative embodiment of the presentinvention. This example, similar to the example illustrated in FIG. 2,illustrates an I/O hub 820 and a PCI bridge 810. As in FIG. 2, connectedwith the I/O hub 820 via a physical communication link 826 is a systemmemory 830. The I/O hub 820 also has an interface 816 for connectionwith the PCI bridge 810. The I/O hub 820 in this example includes aplurality of buffers 821 and 822 for temporarily storing communicationsbetween the PCI bridge 810 and system memory 830.

[0037] The differences between this example and the one illustrated inFIG. 2 are in the PCI bridge 810. In this example, The PCI bridge 810has only a single buffer 814 for temporarily storing communicationsbetween the I/O hub 820 and the bus segments 845 and 855. Additionally,the PCI bridge includes a second internal bus 818 coupled with aexternal bus 870 with which the independent buses 845 and 855 areconnected via a physical link 865. The external bus 870, as will bedescribed below, passes peer-to-peer communications between theindependent bus segments 845 and 855 without passing them through thebridge 810.

[0038] The contents of the independent bus segments 845 and 855 aretransferred to the separate buffers 821 and 822 of the I/O hub 820, viathe single buffer 814 of the PCI bridge 810. To allow the communicationsfrom the independent buses 845 and 870 to be transferred over the singlebuffer 814 of the PCI bridge 810 and mapped to the proper buffer 821 and822 in the hub 820, the bridge 810 labels each transaction based uponthe bus 845 or 855 from which it originated prior to the transactionbeing inserted in the buffer 814. This may be done with an identifiertagged to each transaction which may be used to de-multiplex thetransaction at the I/O hub 820. According to one embodiment of thepresent invention, the identifier comprises a “pipe” designator made upof a combinations of a hub identifier (HubID) and pipe identifier(PipeID).

[0039]FIG. 9 is a block diagram illustrating data flow with a fencecycle in a dual-headed PCI-to-PCI bridge and I/O hub according to analternative embodiment of the present invention. In this example,similar to the example illustrated in FIG. 4, devices 940 and 950 are onseparate, independent bus segments 945 and 955 and are writing andreading data following a producer/consumer model. The device 940 on“pipe” A functions as the producer and the device 950 on “pipe” Bfunctions as the consumer. The data 935 resides in system memory 930while the flag 951 or semaphore resides on the device 950 on “pipe” B,the consumer.

[0040] In this example, the producer 940 writes the data 935 andsubsequently writes 946 the flag 951. The two writes keep in orderthrough the PCI bridge 910. The data write is sent via the I/O hub 920to the system memory 930 while the flag write 946 is a peer-to-peerwrite and is written directly to the consumer 950. Therefore, thisexample is similar to the one illustrated in FIG. 4 except that thewrite flag transaction 946 is conducted between two devices 940 and 950on the external bus 970 rather than being propagated through the bridge910 as in the first scenario illustrated in FIG. 4.

[0041] The PCI bridge 910 has visibility into transactions on theexternal bus 970 and can therefore detect peer-to-peer transactions onthe bus 970. Once a peer-to-peer communication has been detected, thebridge 910 can apply a fence to the buffer 914. This fence will then betransferred to the buffers 921 and 922 of the I/O hub 920.

Appendix A

[0042] Ramin Aghevii, Reg. No. 43,462; William E. Alford, Reg. No.37,764; Farzad E. Amini, Reg. No. 42,261; William Thomas Babbitt, Reg.No. 39,591; Jordan Michael Becker, Reg. No. 39,602; Michael A.Bernadicou, Reg. No. 35,934; Roger W. Blakely, Jr., Reg. No. 25,831; R.Alan Burnett, Reg. No. 46,149; Gregory D. Caldwell, Reg. No. 39,926;Jae-Hee Choi, Reg No. 45,288; Thomas M. Coester, Reg. No. 39,637; RobertP. Cogan, Reg. No. 25,049; Donna Jo Coningsby, Reg. No. 41,684; FlorinCorie, Reg. No. 46,244; Mimi Diemmy Dao, Reg. No. 45,628; Dennis M.deGuzman, Reg. No. 41,702; Stephen M. De Klerk, Reg. No. 46,503; MichaelAnthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813;Justin M. Dillon, Reg. No. 42,486; Sanjeet Dutta, Reg. No. 46,145;Matthew C. Fagan, Reg. No. 37,542; Tarek N. Fahmi, Reg. No. 41,402;Thomas S. Ferrill, Reg. No. 42,532; George Fountain, Reg. No. 37,374;Andre Gibbs, Reg. No. 47,593; James Y. Go, Reg. No. 40,621; Melissa A.Haapala, Reg No. 47,622; Alan Heimlich, Reg. No. 48,808; James A. Henry,Reg. No. 41,064; Libby H. Ho, Reg. No. 46,774; Willmore F. Holbrow III,Reg. No. 41,845; Sheryl Sue Holloway, Reg. No. 37,850; George W HooverII, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; William W. Kidd,Reg. No. 31,772; Walter T. Kim, Reg. No. 42,731; Eric T. King, Reg. No.44,188; Steve Laut, Reg. No. 47,736; George Brian Leavell, Reg. No.45,436; Samuel S. Lee, Reg. No. 42791; Gordon R. Lindeen III, Reg. No.33,192; Jan Carol Little, Reg. No. 41,181; Julio Loza, Reg. No. 47,758;Joseph Lutz, Reg. No. 43,765; Michael J. Mallie, Reg. No. 36,591; AndreL. Marais, Reg. No. 48,095; Paul A. Mendonsa, Reg. No. 42,879; Clive D.Menezes, Reg. No. 45,493; Richard A. Nakashima, Reg. No. 42,023; StephenNeal Reg. No. 47,815; Chun M. Ng, Reg. No. 36,878; Thien T. Nguyen, Reg.No. 43,835; Thinh V. Nguyen, Reg. No. 42,034; Robert B. O'Rourke, Reg.No. 46,972; Daniel E. Ovanezian, Reg. No. 41,236; Gregg A. Peacock, Reg.No. 45,001; Marina Portnova, Reg. No. 45,750; Michael A. Proksch, Reg.No. 43,021; Randol W. Read, Reg. No. 43,876; William F. Ryann, Reg.44,313; James H. Salter, Reg. No. 35,668; William W. Schaal, Reg. No.39,018; James C. Scheller, Reg. No. 31,195; Jeffrey S. Schubert, Reg.No. 43,098; Saina Shamilov, Reg. No. 48,266; Maria McCormack Sobrino,Reg. No. 31,639; Stanley W. Sokoloff, Reg. No. 25,128; Judith A.Szepesi, Reg. No. 39,393; Ronald S. Tamura, Reg. No. 43,179; Edwin H.Taylor, Reg. No. 25,129; Lance A. Termes, Reg. No. 43,184; John F.Travis, Reg. No. 43,203; Kerry P. Tweet, Reg. No. 45,959; Mark C. VanNess, Reg. No. 39,865; Tom Van Zandt, Reg. No. 43,219; Brent Vecchia,Reg No. 48,011; Lester J. Vincent, Reg. No. 31,460; Archana B. Vittal,Reg. No. 45,182; Glenn E. Von Tersch, Reg. No. 41,364; John PatrickWard, Reg. No. 40,216; Mark L. Watson, Reg. No. 46,322; Thomas C.Webster, Reg. No. 46,154; and Norman Zafman, Reg. No. 26,250; my patentattorneys, and Charles P. Landrum, Reg. No. 46,855; Suk S. Lee, Reg. No.47,745; and Raul Martinez, Reg. No. 46,904, Brent E. Vecchia, Reg. No.48,011; Lehua Wang, Reg. No. P48,023; my patent agents, of BLAKELY,SOKOLOFF, TAYLOR & ZAFMAN LLP, with offices located at 12400 WilshireBoulevard, 7th Floor, Los Angeles, Calif. 90025, telephone (310)207-3800, and Alan K. Aldous, Reg. No. 31,905; Ed Brake, Reg. No.37,784; Ben Burge, Reg. No. 42,372; Robert A. Burtzlaff, Reg. No.35,466; Richard C. Calderwood, Reg. No. 35,468; Jeffrey S. Draeger, Reg.No. 41,000; Cynthia Thomas Faatz, Reg No. 39,973; Jeffrey B. Huter, Reg.No. 41,086; John Kacvinsky, Reg. No. 40,040; Seth Z. Kalson, Reg. No.40,670; David J. Kaplan, Reg. No. 41,105; Peter Lam, Reg. No. 44,855;Anthony Martinez, Reg No. 44,223; Paul Nagy, Reg. No. 37,896; Dennis A.Nicholls, Reg. No. 42,036; Leo V. Novakoski, Reg. No. 37,198; LannyParker, Reg. No. 44,281; Thomas C. Reynolds, Reg. No. 32,488; Kenneth M.Seddon, Reg. No. 43,105; Mark Seeley, Reg. No. 32,299; Steven P.Skabrat, Reg. No. 36,279; Howard A. Skaist, Reg. No. 36,008; Robert G.Winkle, Reg. No. 37,474; Sharon Wong, Reg. No. 37,760; Steven D. Yates,Reg. No. 42,242; Calvin E. Wells; Reg. No. 43,256 and Charles K. Young,Reg. No. 39,435, my patent agents, of INTEL CORPORATION; and James R.Thein, Reg. No. 31,710, my patent attorney; with full power ofsubstitution and revocation, to prosecute this application and totransact all business in the Patent and Trademark Office connectedherewith.

What is claimed is:
 1. A method comprising: monitoring a plurality ofbuses connected to the same side of a bridge, the plurality of busescomprising at least a first bus and a second bus; determining whether awrite command issued on the first bus by a first device is apeer-to-peer write command directed to a second device on the secondbus; and causing pending input/output transactions to be temporarilyordered through an I/O hub coupled with the other side of the bridgeresponsive to determining the write command is a peer-to-peer writecommand.
 2. The method of claim 1, wherein said determining whether thewrite command is a peer-to-peer write command is performed by thebridge.
 3. The method of claim 1, wherein said determining whether thewrite command is a peer-to-peer write command is performed by the firstdevice.
 4. The method of claim 1, wherein said causing comprises issuinga fence command.
 5. The method of claim 4, wherein said issuingcomprises writing the fence command into each buffer of a plurality ofbuffers in the I/O hub connected with the bridge.
 6. The method of claim5, wherein the plurality of buffers comprises a plurality of queues. 7.The method of claim 5, wherein said issuing is performed by the bridge.8. The method of claim 5, wherein said issuing is performed by the firstdevice.
 9. The method of claim 1, wherein the first bus is a PCI bus.10. The method of claim 1, wherein the second bus is a PCI bus.
 11. Amethod comprising: reading a first buffer of a plurality of buffers inan I/O hub; determining whether a fence command has been read, the fencecommand indicating a need to temporarily order processing of theplurality of buffers; and responsive to determining a fence command hasbeen read from the first buffer, prohibiting processing of subsequentcommands from the first buffer until a corresponding fence command isread from all other buffers in the plurality of buffers.
 12. The methodof claim 11, wherein the plurality of buffers comprises a plurality ofqueues.
 13. The method of claim 11, wherein the plurality of buffers inthe I/O hub correspond to a plurality of devices on one or more busesconnected with a bridge, the bridge being connected with the I/O hub.14. The method of claim 13, wherein the one or more buses comprise PCIbuses.
 15. An apparatus comprising: an internal bus; a plurality ofbuffers coupled with the internal bus; a physical link to a plurality ofexternal, independent buses; and a processor to determine whether awrite command issued by a first device on a first bus of the pluralityof buses is a peer-to-peer write command directed to a second device ona second bus of the plurality of independent buses and cause pendinginput/output transactions to be temporarily ordered through an I/O hubcoupled with the other side of the bridge responsive to determining thewrite command is a peer-to-peer write command.
 16. The apparatus ofclaim 15, wherein the plurality of buffers comprises a plurality ofqueues.
 17. The apparatus of claim 15, wherein the processor furtherwrites the fence command into each buffer of the plurality of buffers.18. The apparatus of claim 15, wherein the first bus is a PCI bus. 19.The apparatus of claim 15, wherein the second bus is a PCI bus.
 20. Anapparatus comprising: a plurality of buffers; a processor to read afirst buffer of a plurality of buffers in an I/O hub, determine whethera fence command has been read, the fence command indicating a need totemporarily order processing of the plurality of buffers, and responsiveto determining a fence command has been read from the first buffer,prohibit processing of subsequent commands from the first buffer until acorresponding fence command is read from all other buffers in theplurality of buffers.
 21. The apparatus of claim 20, wherein theplurality of buffers comprises a plurality of queues.
 22. The apparatusof claim 20, wherein the plurality of buffers in the I/O hub correspondto a plurality of devices on one or more buses connected with a bridge,the bridge being connected with the I/O hub.
 23. A machine-readablemedium having stored thereon data representing sequences ofinstructions, the sequences of instructions which, when executed by aprocessor, cause the processor to: monitor a plurality of busesconnected to the same side of a bridge, the plurality of busescomprising at least a first bus and a second bus; determine whether awrite command issued on the first bus by a first device is apeer-to-peer write command directed to a second device on the secondbus; and cause pending input/output transactions to be temporarilyordered through an I/O hub coupled with the other side of the bridgeresponsive to determining the write command is a peer-to-peer writecommand.
 24. The machine-readable medium of claim 23, wherein saidbridge determines whether the write command is a peer-to-peer writecommand.
 25. The machine-readable medium of claim 23, wherein said firstdevice determines whether the write command is a peer-to-peer writecommand.
 26. The machine readable medium of claim 23, wherein saidcausing pending input/output transactions to be temporarily ordercomprises issuing a fence command.
 27. The machine-readable medium ofclaim 26, wherein said processor writes the fence command into eachbuffer of a plurality of buffers in the I/O hub.
 28. Themachine-readable medium of claim 27, wherein the plurality of bufferscomprises a plurality of queues.
 29. The machine-readable medium ofclaim 27, wherein said bridge issues the fence command.
 30. Themachine-readable medium of claim 27, wherein said first device issuesthe fence command.
 31. The machine-readable medium of claim 23, whereinthe first bus is a PCI bus.
 32. The machine-readable medium of claim 23,wherein the second bus is a PCI bus.
 33. A machine-readable mediumhaving stored thereon data representing sequences of instructions, thesequences of instructions which, when executed by a processor, cause theprocessor to: read a first buffer of a plurality of buffers in an I/Ohub; determine whether a fence command has been read, the fence commandindicating a need to temporarily order processing of the plurality ofbuffers; and responsive to determining a fence command has been readfrom the first buffer, prohibit processing of subsequent commands fromthe first buffer until a corresponding fence command is read from allother buffers in the plurality of buffers.
 34. The machine-readablemedium of claim 33, wherein the plurality of buffers comprises aplurality of queues.
 35. The machine-readable medium of claim 33,wherein the plurality of buffers in the I/O hub correspond to aplurality of devices on one or more buses connected with a bridge, thebridge being connected with the I/O hub.
 36. The machine-readable mediumof claim 35, wherein the one or more buses comprise PCI buses.